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RPS IANA Issues 
Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 
Abstract 


RPS Security [2] requires certain RPSL [1] objects in the IRR to be 
hierarchically delegated. The set of objects that are at the root of 
this hierarchy needs to be created and digitally signed by IANA. This 
paper presents these seed objects and lists operations required from 
IANA. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119. 


1 Initial Seed 


A public key of IANA needs to be distributed with the software 
implementations of Distributed Routing Policy System [3]. An initial 
set of seed objects are needed to be signed with this key. The 
following transaction (the transaction format is defined in [3]) 
contains these objects and is signed by this key: 
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mnt-iana 

iana’s maintainer 
JKR1 

JKR1 
JKRey@ISI.EDU 
JKRey@ISI.EDU 
pgpkey—7F6AA1B9 
mnt-iana 

mnt-iana 

IANA 


mntner: 
descr: 
admin-c: 
tech-c: 
upd-to: 
mnt-nfy: 
auth: 
mnt-by: 
referral-by: 
source: 


key-cert: pgpkey-7F6AA1B9 

method: pgp 

owner: iana-root (est. Nov 98) <iana@iana.org> 

fingerpr: 71 09 2E 37 71 B8 OA 9C 3B 28 98 B4 F1 21 13 BB 
certif: # this is the real IANA key 

Version: 2.6.2 
mQCNAzZZJ52SAAAEEAJ//C0O1YnlaGuxXyrC16V7FphkRvBmcNU22TPOzrKnK jnWjH5 
sJ5UQnGOpyhDc7 96gqBjY+1TLvPBISFGIPWgxfNk2JQaxxLTDt+tfgqSsiURc/srpp 
XohFAVR/fez8MOecISwvNpFh5VADUFUONi7 ZLUOWVTC4tM5RUONJa81/aqG5AAUR 


tCdpYW5hLXJvb30gKGVzdC4gTm92 IDk4KSA8aWFuYUBpYW5hLm9y2Zz4= 
=sF4q 


t+ettttst 


mnt-by: mnt-iana 
source: IANA 


IANA 
PGPKEY-88BAC849 
http://www.iana.org 


repository: 
repository-cert: 
query-address: 


response-auth-type: none 
submit-address: http://www.iana.org 
submit-—auth-type: none 
expire: 0000 04:00:00 
heartbeat-interval: 0000 01:00:00 
admin-c: JKR1 
tech-c: JKR1 
mnt-by: mnt-iana 
source: IANA 
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as-block: ASO - AS65535 
descr: as number space 
country: us 

admin-c: JKR1 

tech-c: JKR1 

status: UNALLOCATED 
source: IANA 

mnt-by: mnt-iana 


mnt-lower: 


mnt-iana 


inetnum: 0000 = 2992952557255 
netname: Internet 

descr: ip number space 

country: us 

admin-c: JKR1 

tech-c: JKR1 

status: UNALLOCATED 

source: IANA 

mnt-by: mnt-iana 


mnt-lower: 


mnt-iana 


January 2000 


timestamp: 19991001 01:00:00 +00:00 
signature: 
Version: 2.6.2 


+ 
+ 

+ iQCVAWUBOAd3YENJa81/aqG5SAQFVGAP 9Ho2TSLGXiDi 6V1IMcsKY40bO032EtP44dv 
+ tpNWiRRz47WIpMBmzUrQajBDNNXzwgq9r 9mGC7 5PgOMMwIDfvA47o6mnIGdT9XyZz 
+ 
oh 
+ 


s9H1DGOqghk11IjJHOxXFDrBiz3u7eWwEf3vmDCXt 6UYg91UtRKefkWtR5wD101zDMSc 
7Ya7PE6X8SU= 
=sAft 


The above text has no extra white space characters at the end of each 
line, and contains no tab characters. All blank line sequences 
contain only a single blank line. The page break in the text is also 
a single blank line. 


In this case, we assumed that IANA runs its own repository. However 
this is not a requirement. Instead, it may publish this transaction 
with an existing routing registry. 


2 IANA Assignments 
Each time IANA makes an assignment, it needs to create inetnum and 


as-block objects as appropriate and digitally sign them using the key 
in its key-cert object. For example: 
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as-block: ASO - AS500 
descr: arin’s space 
country: us 

status: ALLOCATED 
source: iana 

delegated: arin 

mnt-by: mnt-iana 
inetnum: t2800 0a 282952929 
netname: Internet portion 
descr: ip number space 
country: us 

status: ALLOCATED 
source: iana 

delegated: arin 

mnt-by: mnt-iana 


3 Creating Routing Repositories 


To enable a new routing repository, a repository object, a maintainer 
object and a key-cert object need to be created and digitally signed 
by IANA. For example: 


mntner: mnt-ripe 

descr: RIPE’s maintainer 
auth: <ripe’s choice> 
mnt-by: mnt-ripe 
referral-by: mnt-iana 

admin-c: 

tech-c: 

upd-to: 

mnt-nfy: TE 

source: RIPE 


key-cert: pgpkey-979979 

method: pgp 

owner: 

fingerpr: ga e; 

certif: # this key is for illustration only 


Version: PGP for Personal Privacy 5.0 


+++++ 


mnt-by: mnt-ripe 
source: RIPE 
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repository: 
query-address: 


response-auth-type: 
response-auth-type: 


remarks: 

remarks: 
submit-—address: 
submit-—address: 
submit-auth-type: 
remarks: 
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RIPE 

whois://whois.ripe.net 

PGPKEY-23F5CE35 # pointer to key-cert object 
none 

you can request rsa signature on queries 

PGP required on submissions 
mailto://auto-dbm@ripe.net 
rps-query://whois.ripe.net:43 

pgp-key, crypt-pw, mail-from 

these are the authentication types supported 


mnt-by: 
expire: 
heartbeat-interval: 


maint-ripe-db 
0000 04:00:00 
0000 01:00:00 
remarks: 
source: 


admin and technical contact, etc 


RIPE 


This very first transaction of a new repository is placed in the new 
repository, not in the IANA repository. 


4 Security Considerations 


Routing policy system security document [2] defines an hierarchical 
authorization model for objects stored in the routing registries. 

This document specifies the seed objects and the actions need to be 
taken by IANA to maintain the root of that authorization hierarchy. 


5 IANA Considerations 
This whole document is for detailed consideration by IANA. 
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7 Notices 
The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 


this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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8 Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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